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1.0 Purpose 


This document defines the software developed by the SAO AXAF Mission 
Support (MS) Program and defines standards for the software development 
process and control of data products generated by the software. 


2.0 Introduction 

The SAO MS is tasked to develop and use software to perform a variety of 
functions in support of the AXAF mission. Software is developed by Software 
Engineers and Scientists, and Commercial Off-The-Shelf (COTS) software is 
used either directly or customized through the use of scripts to implement 
analysis procedures. Software controls real-time laboratory instruments, per- 
forms data archiving, displays data and generates model predictions. Much 
software is used in the analysis of data to generate data products that are 
required by the AXAF project, for example, on-orbit mirror performance 
predictions or detailed characterization of the mirror reflection performance 
with energy. 

The challenge faced by the MS Software Team is to provide the appropri- 
ate level of formality to the software development process (documentation, 
testing, verification and validation) while not impeding the scientific process 
and remaining within budget. Software may be developed with a range of 
formality. The most formal approach to software development is formally 
proven software, a lower level might be DOD STD 2167B, then MM 1085.1, 
a Unit Development Folder approach, personally controlled software and fi- 
nally no control (code comments only). In addition to the software process, 
the data products generated from the software need to be controlled such 
that the software version, documentation (algorithms etc.), input parame- 
ters and output data are linked and controlled. The control and traceability 
of software data products combined with the appropriate level of software de- 
velopment formality is the key to the effective management of a large body 
of non- deliverable software vital to the success of AXAF. 

Our approach is to classify software according to the required formality of 
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the software development process, define a standard applicable to the most 
formal software and tailor the standard to the other classes. 


3.0 Classification Schemes 

In this section, we shall define the method by which software and data prod- 
ucts are classified within SAO MS. In Sections 3.1 and 3.2, we describe the 
types of software and data generated and used by SAO MS. In Sections 3.3 
and 3.4 we define four degrees of formal control and guidelines classifying 
software and data products. Finally, in Section 3.5, we define the actual 
software and data configuration items. 


3.1 Functional Classification of MS Software 

A wide variety of software is used by SAO MS and it is instructive to classify 

the software according to the function that it performs. According to func 

tion, SAO developed software may be divided into the following categories: 

Deliverable GSE software: software controlling ground support equip- 
ment (GSE). This software is necessary for the proper functioning of 
GSE and therefore must be stringently controlled 

Laboratory Control software: software controlling laboratory equipment. 
Insofar as this laboratory data is dependent on the proper functioning 
of this software, this software must be stringently controlled. 

Analysis and Modeling software: software used in analyzing the results 
of measurements and resulting in predictions concerning the perfor- 
mance of the AXAF-I observatory. This software needs to be controlled 
to an extent commensurate with the mission impact of the predictions 
it makes. 

Prototype software: software used to prototype new techniques in areas 
such as modeling, data analysis, and instrument control. This software 
is loosely controlled in keeping with its volatile nature. 
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3.2 Descriptive Classification of MS Data Products 

A wide variety of data products are used and generated by SAO MS. These 
data products may be classified by the following categories: 

Reduced Laboratory Data: results of analysis and reduction of experi- 
mental laboratory data such as reflectivity curves and optical constants. 
This data is controlled to an extent commensurate with mission impact. 

Reduced Simulation Data: results of analysis and reduction of data ac- 
quired by simulation and modeling such as studies based on ray tracing. 
This data is controlled to an extent commensurate with mission impact. 


3.3 Levels of Control for Software 

The degree of control used for SAO MS software is determined primarily by 

the direct and indirect impact the software has upon the AXAF mission. For 

SAO MS generated Software, four levels of control are defined as follows: 

Level I SW: Deliverable SW. Level I SW will be controlled in the manner 
of Level II SW. Furthermore, Level I SW may have additional -controls 
to bring it in conformance to its associated Data Requirement (DR). 

Level II SW: Mission Support Controlled SW. Level II SW is used for soft- 
ware with major mission impact. Level II SW include software used 
for making predictions used for making critical mission decision and 
software used for performing critical mission tasks. 

Level III SW: Personal control SW. Level III SW has only minor mis- 
sion impact. Examples of Level III SW include software developed 
to perform preliminary calculations to test spacecraft requirements or 
software for initial reduction of laboratory data. 

Level TV SW: No formal control required. Level IV SW has no immediate 
mission impact and is typically software generated for prototyping or 
for explorative calculations. 
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A detailed description of each level is given in Section 4 

In addition to SAO MS generated software, SAO MS also uses the following 

types of software: 

COTS and PD: Commercial Off the Shelf software and Public Domain 
software include compilers, editors, statistical analysis packages, hard- 
ware drivers, and other commonly available software. These packages 
have been verified by agencies external to SAO and through common 
use. COTS and PD software is not developed further by SAO and SAO 
typically imposes no formal controls. 

4GL SW: Fourth Generation software is software used to integrate existing 
SW packages (e.g. COTS/PD SW, SAO developed SW, library routines 
such as IMSL, NAG, IDL math functions, SAOLIB). 4GL software of 
modest complexity is typically controlled as Level III software. 


3.4 Levels of Control for Data Products 

The degree of control used for SAO MS data products is determined primarily 
by the direct and indirect impact the data product has upon the AXAF 
mission. For SAO MS generated data products, four levels of control are 
defined as follows: 

Level I Data: Program controlled data. Level I data is data with major 
mission impact that must be delivered to the AXAF program in a 
predetermined format. Level I data will be controlled in the manner of 
Level II data. Furthermore, Level I data may have additional controls 
to bring it in conformance to its associated Data Requirement (DR). 

Level II Data: Mission Support Controlled data. Level II data is data with 
major mission impact. Level II data products are used for making 
mission critical decisions and incorporated in mission critical tasks. 

Level III Data: Personal control data. Level III data has only minor mis- 
sion impact. Examples of Level III data are results of analysis and 
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reduction used in technical memoranda and reports which do not af- 
fect mission scope or critical mission requirements. 

Level IV Data: No formal control required. Level IV Data has no imme- 
diate mission impact and is typically data gathered from exploratory 
or prototype calculations and measurements. 

In addition to the above mentioned data products, SAO MS also uses COTS 
and PD data. COTS/PD data are published measurements and mathemat- 
ical functions available commercially or are in the public domain. This data 
has been verified by agencies external to SAO and through common use. 
COTS/PD data is not developed further by SAO and SAO typically imposes 
no formal controls. 


3.5 Configuration Items 

Configuration identification of software is established via the SAO UDF 
which includes the following: 

1. Requirements and design documentation. 

2. User documentation. 

3. Software testing results. 

4. Complete computer source code. 

5. Change log. 

Configuration identification of data products is established via a Data Note- 
book which includes the following: 

1. Mathematical specification of analysis and reduction algorithms and 
techniques. 

2. Enumeration of software packages used and input parameters 
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3. Results of consistency tests 

4. Raw data used. 


4.0 Tailored standards 

In Section 4, we present a matrix of how SAO MS tailors the degree of formal 
control of software and data products. In particular, the degree of configu- 
ration management, organizational management, documentation standards, 
and verification are presented. 


4.1 Configuration Management Levels 

The configuration items for software and data products (the UDF and Data 
Notebook, defined in Section 3.5) shall be controlled at varying levels of 
formality. In all cases above Level IV, version and revision control shall be 
maintained. This enables one to repeat a calculation or a measurement at a 
later date. 

The levels of configuration management are defined as follows: 

Level I: control by SAO AXAF Program Configuration Manager in con- 
junction with SAO MS Software Configuration Manager. In addition 
to individual control, SAO MS control, configuration control is main- 
tained at the program level in accordance with the SAO Configuration 
Management Plan (SAO-HEAD-PLAN-93-034) as well as with any ad- 
ditional requirements imposed by DR. 

Level II: control by SAO MS Software Configuration Manager. In addi- 
tion to individual control, configuration is maintained in the SAO MS 
library and accessible by all members of SAO MS. 

Level III: version control by individual scientist or engineer. 

Level IV: no required control. 
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4.2 Organizational Management 


The organizational complexity in managing software development or data 
acquisition varies with the level of control. The levels of organization are 
defined as follows: 

Level I: hierarchical management with teams of scientists and engineers. 
The organization of each team shall be tailored to the complexity of the 
project. This organization shall be documented to the extent required 
by DR. 

Level Hi hierarchical management with teams of scientists and engineers. 
The organization of each team shall be tailored to the complexity of 
the project. 

Level III: managed by individual scientist or engineer. 

Level IV: managed by individual scientist or engineer. 


4.3 Technical Documentation 

The detail and content of the technical documentation for software and data 
products shall be determined by the level of control. Documentation is typi- 
cally made by means of the SAO Unit Development Folder (UDF) for software 
and SAO Data Notebook for data products. The levels of documentation are 
defined as follows: 

Level I: SAO UDF for software and Data Notebook for data products. UDF 
and Notebook shall be maintained in the SAO MS library and accessible 
by all members of SAO MS. Any additional documentation required by 
DR shall be provided. 

Level II: SAO UDF for software and Data Notebook for data products. 
UDF and Notebook shall be maintained in the SAO MS library and 
accessible by all members of SAO MS. 
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Level III: SAO UDF for software and Data Notebook for data products. 
Level IV: no documentation requirements. 


4.4 User Documentation Standards 

The detail and content of user documentation for software and data products 
shall be determined by the level of control and the potential user base. SAO 
MS documentation is typically based upon the UNIX man page. The levels 
of user documentation are defined as follows: 

Level I: documentation required at a level comparable to the UNIX man 
page. Any additional documentation required by DR shall be provided. 

Level II: documentation required at a level comparable to the UNIX man 
page. 

Level III: documentation required at a level comparable to the UNIX man 
page. 

Level TV: no documentation requirements. 


4.5 Methods of Verification and Validation 

Depending on the nature of the software and data product, different method- 
ologies for verification and validation (V&V) are appropriate. Here we extend 
a TRW classification of V&V methods (Rogson, 6th SSWG presentation, 
April 1993): 

Direct Testing consists of comparing data products or software function 
with results known to be correct. Results may be known to be correct 
either by requirements definition or by mathematical tautology. 

Comparison consists of two or more agencies applying independently devel- 
oped algorithms and software to the same input data. If their results 
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agree, it may be presumed that each set of software, the algorithms 
involved, and the resulting data products are correct. 

Consistency consists of using data derived from two or more separate tests 
and comparing results where the test results overlap. Inconsistent re- 
sults indicate that either the test equipment or the programs involved 
are in error. Consistency indicates that the results are correct in the 
areas of overlap. 

Common use consists of using software or data products that is used by 
a large audience on a common basis. The widespread use constitutes 
verification by agencies outside SAO MS. This type of verification is 
applicable to most COTS/PD software and data products. 

Previous use consists of using software or data products which has been 
used extensively in the past by members of SAO MS or other agencies 
and has produced documented reliable results. Documented previous 
experience may constitute sufficient verification for SAO MS. 

SAO MS requires that all software and data products above Level IV be 
verified and validated by one or more of the above methods. Validation 
of SAO MS software and data products will use direct testing whenever 
feasible. The precise V&V tests shall be determined on a case by case method 
and documented in the SAO UDF for software and the SAO Data Notebook 
for data products. 


Appendix A; MS Software and Data Products 

In this section, we list software and data products in use by SAO MS broken 
out by their entry in the SAO MS Work Breakdown Structure (WBS). The 
lists are not all inclusive, but instead, give a representative picture of software 
and data products at SAO MS. 
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A.l WBS and Software 


The following table gives a partial list of the names and classifications of 
software packages used to support each SAO MS WBS task. 


WBS Task 

Function 

SW Package 

SW Class 

Verif. 

3.2.1 

ray trace 

OSAC, MIRROR 

COTS PD 

a,b,c,d 

Optical System 

FEM 

ANSYS 

COTS PD 

a,b,c,d 

Performance 

metrology fits 

TRANSFIT 

Level 11 

b,c 


Visualization 

IDL 

COTS PD 

b,c,d 

3.2.2 

raytrace 

OSAC, MIRROR 

COTS PD 

a,b,c,d 

X-ray System 
Performance 

ray trace 

fit.OSAC 

Level II 

a,b,c,d 

3.2.3 

raytrace 

OSAC, MIRROR 

COTS PD 

a,b,c,d 

HRMA 

Visualization 

IDL, IRAF 

COTS PD 

b,c,d 

Calibration 

Spectral fits 

fitHRMA 

Level II 

a,b 


Database 

RDB 

COTS PD 

b,c,d 

4.4 

Database 

RDB 

COTS PD 

b,c,d 

HXDS SW 

Visualization 

IDL, IRAF 

COTS PD 

b,c,d 


XDS control 

HXDSsw 

Level I 

b,c 

6.1 

Database 

RDB 

COTS PD 

b,c,d 

Reflectivity 

Visualization 

IDL, IRAF 

COTS PD 

b,c,d 

Studies 

lab control 

HXDSsw subset 

Level II 

b,c 

6.2 

Database 

RDB 

COTS PD 

b,c,d 

Synchrotron 

Visualization 

IDL 

COTS PD 

b,c,d 

Studies 

lab control 

XIXON 

COTS PD 

b,c,d 

Verification key: a) comparison, b) consistency, c 

) previous use, d) common use . 


A. 2 WBS and Data Products 

The following table gives a partial list of the names and classifications of data 
products being generated by each SAO MS WBS task. 
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WBS Task 

Data Product 

Data Class 

Verif. 

3.2.1 

HRMA FE model 

Level II 

a,b,c 

Optical System 
Performance 

Cygnus xcheck 

Level II 

a,b,c,d 

3.2.2 

tilt analysis 

Level III 

a,b 

X-ray System 
Performance 

vignetting analysis 

Level 111 

a,b 

3.2.3 

HRMA 

Calibration 

HXDS error budget 

Level III 

a,b 

4.4 

VXDS timing model 


a,b 

HXDS SW 

HXDS timing model 


a,b,c 

6.1 

reflectivity model 

Level II 

a,b 

Reflectivity 

Studies 

coating analysis 

Level II 

a,b 

6.2 

reflectivity model 

Level II 

a,b 

Synchrotron 

optical constants 

Level II 

a,b 

Studies 

contamination study 

Level III 

a,b 

Verification key: a) comparison, b) consistency, c) previous use, d) common use. 
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Appendix B: Acronym List 


AXAF 

Advanced X-ray Astrophysics Facility 

COTS/PD 

Commercial Off the Shelf / Public Domain 

DR 

Data Requirement 

FEM 

Finite Element Model 

GSE 

Ground System Equipment 

HRMA 

High Resolution Mirror Assembly 

HXDS 

HRMA X-ray Detection System 

MS 

Mission Support 

SAO 

Smithsonian Astrophysical Observatory 

SSWG 

Software Systems Working Group 

UDF 

Unit Development Folder 

V&V 

Verification and Validation 

VETA 

Verification Engineering Test Article 

VXDS 

VETA X-ray Detection System 

WBS 

Work Breakdown Structure 

XDS 

X-ray Detection System 
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